Wolf3D - Amiga Codex: STL/Damage(SF) C2P combination of c2p_020_fastram and c2p4.a Gfx: STL Quality Assurance and High Depressing: Friends :) V1.0 16..17.12.94, (pre)^n release and obsolete as well as V1.1. V1.1 followed some days later as a quick re-release after improvements. Changes after V1.1: · Game engine optimized and lots of shit kicked out from the ray routines. · Document mistakes corrected. V1.2 release date 26.12.94. Changes after V1.2: · Doors (basically pretty ready, but yet disabled for unsubdividional reasons) · Real dithering (or actually not, but should fool you :) · EHB/OCS and 256/AGA colour modes. · The usage of blitter added to the C2P routine. · Faster, optimized etc... V1.3 released? Dunno... :) · Anyway, even more optimizations, HD crashes (not caused by the Wolf though :) and other nice surprises (My HD's PSU blew up... Sigh)... V1.4 release: this hopefully also spread... V1.5 release 15.5.95 (the magic three 5s) · Floor/Ceiling texture mapping · Bigger screen V1.6_BUG_kill-1 - release V1.6.1 · Looks better due to the increased amount of decimals (my fault at V1.5) · Faster (At least 8x192x48 cycles on the bigger screen per screen calc) · Even more faster (floor routine optimized) · Ray tracing faster (Speedy speed the third time!) · The bug that crashed V1.5 is now removed. · Corrected a perspective bug. · Sprite fading added. · AGA and OCS modes now included in the same file! Switch with F10. The reason for the arrival of the V1.6 is the fact that V1.5 tend to crash when the demo compiled the first screen. The crash was an immediate screen going foom and system halt, crash and guru when the precalculating had finished. It was caused by the fact that AmigaDOS doesn't clear bss areas before running the demo. Since assembler does this, I never received any problems. The unclearance of bss caused uninitialized data areas, and the thing that crashed it all was a tiny little word of memory, that stated the amount of tasks the blitter had left to do. This particular little word inherited the value the last task had left at that particular point in memory. Even a value of 64 (can be from zero to 65536) is high enough to make the blitter run through most of the chip memory, messing everything on its path. This counts interrupt pointers, exec pointer and exec.library for the system, and graphics for the engine. One of the Murphy's laws is that the bugs never appear before the release date! Then to the other type of fatal crash bug that has been reported to me. It may currently occur on 68020++, and I have been told that disabling the duplication of the zero page to the fast memory made the demo work. Could simply boil down to the 1st bug too, as this changes the memory assignment a little. The person telling me this assumed exeption/interrupt register setup failure. The upshot for copying the zero page is that fast memory is faster to access and thus it boosts up AmigaDOS little. Since this is MMU-only feature, it doesn't cross the paths of anyone else. And some MMU people can annoy themselves with Enforcer hits, too. Anyway, I once read a document about MMUs and zero pages, and I don't remember any mentions about crash possibilities. Try this anyway, if everything else fails. This is an UnCertain Area for me, could anybody help me out? :) I have been told that the AGA looks insanely identical to the OCS version. That is, they are actually VERY identical. The only difference between OCS and AGA is the amount of colours and an improved palette (256 colours - 24 bit)! To the question of creating a game, I am open for game contracts :) .. I'm already coding a game, though. Real mem loss anyway. About 500kB of mem will be needed for the graphics if a game will be done, having three enemies and nice design, just like in the official PC game Wolfenstein 3D. Now to the almost intact original V1.5 Info text... MAIL: andezl@kastelli.otol.fi IRC: Check out STL!andezl@* on #amiga or #amigascne This demo is made for an interest in coding a FAST similar 3D routine that is used in Wolfenstein (or why not better while on it :) For a long time, that was not possible due to the lack of algorithms required to the rendering of a 3D screen from a simple 2D map. The last kick needed came from the documents written by Brian Marshall. Without him, this demo would not exist. Also extra thanks to Count Zero for supplying me with those documents. And most thanks to Peter McGavin for his fine Chunky sources. The hardware requirements are kept to minimum in order to make this accessible for everyone. The only limit is the EHB mode, which (as I recall) limits out the A1000 machines, which don't have it. Features: · Two screen sizes, 128x96 and 192x160. · Two colour modes, 64_EHB-OCS and 256-AGA. · Floor, ceiling and wall Texture mapping. · Depth cueing with realtime texture dithering. · Sprites. *** Here are the keyboard controls for the game. Mitsumis are welcome and others are not. A1200 is especially unstabile. Key detection fails, key releases may be left undetected, matrix fails and other general shit. Well, not fatal though. Most of the time it works (= at least 50% of cases). Strange though. There are no dbf wait loops, but a vblank line -loop to ensure that enough time gets waited (read: wasted). It seems that the actual keyboard of A1200 and some other keyboard types can't detect all the combinations of multiple key strokes. Most of the A500's keyboards (That is Mitsumi, I suppose) have the n-key rollover, which means that you haven't got enough fingers to mess up the matrix. It seems very easy on the 1200 though. Annoying. If anybody knows a proper, errorproof way to hardware read keyboards on non-Mitsumis with simultaneous keypresses available, please tell me. That would help lots of people. It seems that some of those qualifier keys are errorproof. Nice thing, but not too helpful. ESC/LMB=quit Joystick Fire/R-ALT=fire current weapon. N/A R-Amiga=modify turn left/right keys to do sidewalk. N/A Space=open door. N/A Shift=running mode, also available on numeric. Numeric keyboard controls: [ ] / * sidewalk left move forwards sidewalk right 7 8 9 - turn left move forwards turn right 4 5 6 + turn left move backwards turn right fire weapon N/A 1 2 3 E turn left move backwards turn right open doors N/A 0 . running mode Another method for primary controlling, although more limited, is to use arrow keys. This helps with the A1200's keyboard. Even more helpful is to leave the whole keyboard intact and grab a joystick instead. The Engine ---------- What's new? The view is completely texture mapped, in contrary to the V1.4 version that had only the walls texture mapped. Now mapping includes walls, floors, ceilings, sprites and doors (that are faked yet!). All the walls, ceilings and floors are faded and dithered according the depth and the type of the texture block (floor is the darkest, ceiling little lighter and wall receives the maximum light) to accomplish the view perfection to the eye. The floor/ceiling routine was started from scratch and has reached the current form after 12 hours of optimizing/developing. This routine is the thirth one I have made for such purpose. It is at least the fastest I have seen anywhere so far. Sorry for not having an actual floor/ceiling texture selection map. Will be done some day. Here's a little comparision that I have made to the leading Wolf Clone (in my opinion), that is yet very similar to my own: Nearest match is POOM, and I talk about the version demonstarted in Parallax's demo Drool This. What makes DamageWolf better than POOM? - Soft fading, lots of entirely differing colours and only 64 colours used (AGA uses full 256 colour palette, of course). - Ceiling and floor are independent in both the lighting level and texture. Any texture could be selected, but this is yet limited. (I think POOM mirrors ceiling to floor (or the other way), fast and simple solution) - Smaller memory usage (this means worse textures, though) - Texture Dithering (gives more than 120 rastered colours) - Very long distance view (one ray is traced at least 40 squares of map before it is assumed never to hit anything), I believe the farthest on Amiga. - Faster/Equal speed (Actually I don't know, Drool This run on 68030/50 without any framerate information except the one given by analog measuring equipment, ie. my eyes and the size of the view wasn't mentioned (or I didn't catch it)) What DMGWolf misses compared to POOM? - Doors (although POOM's doors can be easily managed) - Nice textures, animation, 128x128 blocks etc... (I am NOT a GFXian.) - POOM has larger screen. Of course I have seen some other Wolfs, too, but they hardly match with mine's. I'm waiting for TextDemo5, which should have all kinds of neat stuff, and I want to see Alien Breed 3D as well... And of course the next release of POOM :) I have been told that there are even more good Wolf clones, some even having 2 player playing possibilities, split screen, modem support.. Due to the lack of AGA and 68020 (and modem), they render their unexsistence to me. Actually all of them would :( .. I wonder if anyone else continues supporting the A500? General info ------------ This Wolfenstein uses ray firing and nothing else to draw the view. The ray firing is specially optimized to be able to trace all the mindbursting distances there are in very fast manner. However, rayfiring means that the walls have to be at 90° degrees with each other. Any texture can be selected for wall blocks, and the wall blocks can be transparent. There is currently only one light source (or actually no light sources at all, but general fading from the player), and I think it will remain this way. The AGA usage has improved. Last time there was 256 colours. Now there is also an 24bit palette, which means much nicer fading. Anyway, it is pretty hard to support AGA without being able to test the routine at all. I noticed a flaw in the blitter buffering, and I corrected it. Last time the C2P left the previous screen unsecured for a little while - about 33% of a frame, which could have malfunctioned on somebody's 68060 :) I can guess that this wasn't actually very significant improvement :) .. C2P now sorts everything out perfectly. The door sprites are removed, as the routine can't support them anymore due to MAJOR changes in the screen drawing algortihm tabling sequences. The doors can still be added, of course. Perhaps I will create the real textured doors next. And the last note is that the Texture Dithering process has bugs. This appears as sudden hiliting of some colours/dithering componenets. Don't know what causes this. Anyway, all this little finishnessless is due to the fact that I haven't yet cared about them too much. Well, there will be re-releases in case this version turns out to have more bugs than advantages :) The graphics may change to real AGA ones for next release after/during summer. B.B: it is up to you :) I access Internet via my school, and from now on I have to use other means. The result is that I can visit to read my mailbox pretty rarely. So don't wonder if my responses take time. *** Enough. N-joy, have fun, explore. Hope it works this time little better. If you have comments, suggestions or questions, just mail me. Any mail would be most welcome. * STL / Damage --- Antti Lankila --- andezl@kastelli.otol.fi * * ^^^ = IRC - - MAIL *